Multiple logical representations of audio functions in a wireless audio transmitter that transmits audio data at different data rates

ABSTRACT

Embodiments of the invention relate generally to electrical and electronic hardware, computer software, wired and wireless network communications, and computing devices. More specifically, the embodiments related to structures and techniques for implementing multiple logical representations of audio functions in a wireless audio transmitter, such as a USB dongle configured to transmit and to receive audio data wirelessly via, for example, a Bluetooth link. In one embodiment, a wireless USB audio transceiver can include a multiple mode transmitter configured transmit wireless signals at multiple data rates. Further, the wireless USB audio transceiver can include a first data path modeled as a first audio function, and a second data path modeled as a second audio function. Also, included is a signal detector configured to determine the presence of the audio data on a data path for modifying transmission data rates as a function of the presence of the audio data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Non-provisional patentapplication Ser. No. 13/247,975, filed on Sep. 28, 2011, and entitled,“Multiple Logical Representations of Audio Functions in a Wireless AudioTransmitter that Transmits Audio Data at Different Data Rates,” whichclaims the benefit of U.S. Provisional Patent Application No.61/511,541, filed Jul. 25, 2011, and entitled “Multiple LogicalRepresentations of Audio Functions in a Wireless Audio Transmitter thatTransmits Audio Data at Different Data Rates,” all of which is hereinincorporated by reference for all purposes.

FIELD

Embodiments of the invention relate generally to electrical andelectronic hardware, computer software, wired and wireless networkcommunications, and computing devices. More specifically, theembodiments related to structures and techniques for implementingmultiple logical representations of audio functions in a wireless audiotransmitter, such as a USB dongle configured to transmit and to receiveaudio data wirelessly via, for example, a Bluetooth link.

BACKGROUND

Functionalities of computing devices have been enhanced with theimplementation of supplemental communication devices, such as the wiredimplementation of Universal Serial Bus (“USB”) for exchanging databetween a host computing device and other devices, such as peripherals.USB dongles provide portable and/or temporary enhanced functionalitiesto a host computing device when coupled via a USB port to the hostcomputing device. Wireless USB dongles provide a host computing devicewith a wireless communication link to peripherals. Further, USB donglescan provide different functions, such as storage and communications.

Conventionally, USB dongles are configured to model each function, suchas storage and audio, as a unitary function. For example, traditionalwireless USB dongles model all audio-related functionality as a singleaudio function, which is described as set forth in the Universal SerialBus Device Class Definition for Audio Devices, Release 1.0, Mar. 18,1998. Thus, most audio-related control and data signals are typicallymodeled in connection with an audio function, or as a single USB audiodevice.

While the conventional approach is functional, it is not well-suited foruse across various proprietary computing platforms and operatingsystems. For example, some operating systems are designed to accessmultiple audio-related control and data functions simultaneously, whichcan produce unintended consequences or otherwise limit the use of a USBdongle. Further, conventional wireless USB communication dongles are notwell-suited to adapt to usage of multiple audio and/or visualcommunication peripherals. Traditionally, wireless USB communicationdongles are configured to communicate data at fixed frequencies so asnot exceed bandwidth limitations of the wireless transmitter andreceiver capabilities.

Thus, what is needed is a solution for wireless devices without thelimitations of conventional techniques to manage data communicationswith communication devices and/or wireless peripheral, such as speakers.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments or examples (“examples”) are disclosed in thefollowing detailed description and the accompanying drawings:

FIG. 1 is a diagram depicting a functional block diagram of a wirelessaudio transceiver, according to various embodiments;

FIGS. 2A and 2B depict examples of various implementations of wirelessaudio transceivers, according to various embodiments;

FIG. 3A illustrates an example of a topology of audio functions,according to an embodiment;

FIG. 3B illustrates an example of a descriptor hierarchy of a USB audiogateway, according to some embodiments;

FIG. 3C illustrates an example of a host computer and a USB audiogateway during enumeration, according to some embodiments;

FIG. 4 illustrates an example of a signal detector operating in relationto logical representations of audio functions, according to someembodiments;

FIG. 5 illustrates an example of a flow for implementing multiplelogical representations of audio functions to modify the data rate ofwireless transmissions, according to some embodiments; and

FIG. 6 illustrates an exemplary USB audio gateway in accordance withvarious embodiments.

DETAILED DESCRIPTION

Various embodiments or examples may be implemented in numerous ways,including as a system, a process, an apparatus, a user interface, or aseries of program instructions on a computer readable medium such as acomputer readable storage medium or a computer network where the programinstructions are sent over optical, electronic, or wirelesscommunication links. In general, operations of disclosed processes maybe performed in an arbitrary order, unless otherwise provided in theclaims.

A detailed description of one or more examples is provided below alongwith accompanying figures. The detailed description is provided inconnection with such examples, but is not limited to any particularexample. The scope is limited only by the claims and numerousalternatives, modifications, and equivalents are encompassed. Numerousspecific details are set forth in the following description in order toprovide a thorough understanding. These details are provided for thepurpose of example and the described techniques may be practicedaccording to the claims without some or all of these specific details.For clarity, technical material that is known in the technical fieldsrelated to the examples has not been described in detail to avoidunnecessarily obscuring the description.

FIG. 1 is a diagram 100 depicting a functional block diagram of awireless audio transceiver, according to various embodiments. As shown,a wireless audio transceiver 110 includes a port 107, a communicationchannel controller 112, a wireless controller 114, a signal detector116, and a transceiver 119, which is shown to include a wirelessreceiver (“RX”) 117 and a wireless multiple-mode transmitter(“Multi-Mode TX”) 118. While wireless audio transceiver 110 and itsconstituent components can be implemented in hardware or software, or acombination thereof, wireless audio transceiver 110 can be modeled suchthat sub-audio functions and/or individual audio-related control anddata signals can be represented as different logical entities. A logicalentity can be implemented as a data representation 109 (e.g., a dataarrangement or structure). For example, FIG. 1 depicts that a first datapath can be modeled by a first data representation or arrangement,whereby the first data arrangement constitutes an audio function (“1”)111. A second data path can be modeled by a second data representationor arrangement, whereby the second data arrangement constitutes anotheraudio function (“2”) 113. Audio function 111 represents a first datapath for transmitting audio data from communication channel (“comm.channel”) 106 to wireless links 124 and 125, with wireless links 124 and125 being associated with one or more data rates. Audio function 113represents a second data path for transmitting audio data from wirelesslink 122 to communication channel 106. Further, wireless audiotransceiver 110 is configured to modify transmission rates oftransceiver 119 based on activity associated with the first data path orthe second data path. Signal detector 116 is configured to detect dataactivity on one or more data paths. For example, signal detector 116 canbe configured to detect whether data (e.g., audio data for audiofunction 2, or AF2 data) is present or available to audio function 113and/or is on the second data path. Depending on whether audio data ispresent or absent relative to audio function 113 and/or the second datapath, multiple-mode transmitter 118 can transmit at different datarates, the transmission rate being a function of whether audio data ispresent or absent on the second data path. Multiple-mode transmitter 118is configured to operate in at least two modes, a telephony mode inwhich voice data is being transmitted and received, and a non-telephonymode in which the bandwidth of the wireless links is available to streamsound data, such as music data, to speakers.

In view of the foregoing, wireless audio transceiver 110 can be modeledlogically as two or more audio functions. Further, wireless audiotransceiver 110 can modify its wireless transmission rates to providesufficient amount of audio data via the wireless links as permitted bythe bandwidth limitations of the wireless links. As to the former,modeling the first and second data paths as different audio functionscan enhance the robustness, reliability and/or operability of wirelessaudio transceiver 110. For example, by modeling each of the data pathsas separate logical entities, each data path can be accessed orcontrolled individually without affecting operation of the other audiofunctions (as other logical entities). Therefore, various operatingsystems can access one data path (as one logical entity) withoutdisturbing another data path (or another logical entity), which mightotherwise be the case if multiple data paths are modeled as part of asingle logical entity. For example, some operating systems, such asMacintosh (“Mac”) operating systems, may access different components ofdifferent data paths at the same time when multiple data paths aremodeled as part of a single audio function. In this case, the presenceor absence of data on one data path (e.g., the data path carryingmicrophone data) can be coupled to another data path (e.g., the datapath carrying speaker data), thereby impeding the identification ofactivity on an individual data path for subsequently determining whetherto modify transmission rates by multiple-mode transmitter 118. Thus,multiple logical entities and data representations of the data pathsfacilitate decoupling or isolating endpoints and buffers that otherwisemight be coupled together. With enhanced, robust data integrity for thedata paths in different audio function entities, wireless audiotransceiver 110 can be configured to monitor the activity of at leastone data path to determine whether to modify the transmission rates bymultiple-mode transmitter 118 of another data path (or portion thereof).By changing the transmission rates of the wireless links, wireless audiotransceiver 110 can optimize the delivery of sufficient amount of audiodata to preserve or enhance the audio quality at, for example, awireless headset or at a wireless speaker.

In operation, signal detector 116 is configured to detect whether a datasignal (e.g., an audio signal) is present or absent on one of the datapaths. For example, signal detector 116 monitors a second data pathassociated with audio function 113, where the audio data beingtransported can be microphone data. In cooperation with signal detector116, multiple-mode transmitter 118 can dynamically and adaptively changethe data rates with a logical communication device 130 and/or a logicalmedia device 132, such as a speaker (or any other media deviceconfigured to consume audio or visual data), depending on the activitybetween logical communication device 130 and logical media device 132and wireless audio transceiver 110. Logical communication device 130 canbe any device, such as a headset or a mobile phone, that is configuredto exchange data, such as telephony data, in a two-way manner such thatit receives data from and transmits data to wireless audio transceiver110, according to some embodiments. Further, logical communicationdevice 130 can operate optionally as a media device when operating in anon-telephony mode (e.g., for receiving data as a one-waycommunication). For example, a headset operating with a disabledmicrophone can behave as a media device (e.g., speaker) operating toreceive sound data, such as streaming music. Thus, the headset canoperate in a non-telephony mode to receive audio data at a second datarate, and can operate in a telephony mode to receive audio data at afirst data rate, with the second data rate being greater than the firstdata rate.

When there is no microphone data present on the second data path, signaldetector 116 infers that wireless audio transceiver 110 is operating ina non-telephony mode. Note that signal detector 116 can be configured todetermine whether wireless audio transceiver 110 is in a first mode or asecond mode, according to some embodiments. For example, signal detector116 can detect the presence of audio data on a second data path bydetermining whether a related buffer includes voice data. Or, signaldetector 116 can detect the presence of audio data on a second data pathby monitoring activity directly on the second data path. Also, signaldetector 116 can detect the presence of audio data on a second data pathby receiving a signal or a message (e.g., from host computing device104) that such a condition exists. Signal detector 116 can determinewhether to invoke changes in the transmission rates in response to avariety of conditions.

In the non-telephony mode, wireless audio transceiver 110 is notexchanging voice or other data over wireless links 122 and 124 with alogical communication device 130, which can be any communication device,such as a headset, that can communicate via wireless channel 120.Logical communication device 130 can be Bluetooth headset configured touse voice over IP (“VoIP”) technologies to establish VoIP telephonycalls originating from network 102, which can be the Internet. Inresponse, multiple-mode transmitter 118 allocates the bandwidth ofwireless channel 120 to wireless link 126, whereby relatively large (orsufficient) amount of data can be transmitted to a speaker 132 toproduce higher quality of sound. Thus, the speaker data isuni-directional. By contrast, in the telephony mode, wireless audiotransceiver 110 exchanges voice and other data over wireless links 122and 124 with logical communication device 130. Signal detector 116 isconfigured to detect the presence of the voice data over the second datapath, which includes wireless links 122 and 124, and is furtherconfigured to communicate the detected presence of voice data withmultiple-mode transmitter 118. In response, multiple-mode transmitter118 can modify the amount of audio transmitted to speaker 132 to ensurebandwidth of wireless channel 120 is shared among wireless links 122 and124. Thus, the voice data is bi-directional. Speaker 132 can operate ina higher quality mode (e.g., when no voice data is present) or in alower quality mode (e.g., when voice data is present). Receiver 117 canbe configured to receive data, such as voice or microphone data, from aheadset via wireless link 122.

In some cases, signal detector 116 can be configured to detect thepresence of the voice data over the second data path during periods oftime when sound data is absent on the first data path. In this case,voice data can be transmitted via wireless link 124 in higher qualityand/or stereo, as bandwidth of wireless channel 120 can be devoted tological communication device 130. But when sound data is again presenton the first data path during active communications between wirelessaudio transceiver 110 and logical communication device 130, signaldetector 116 can detect the presence of the sound data and invokemultiple-mode transmitter 118 to change the transmission rate alongwireless link 124 from its relatively higher data rate to a lower datarate (e.g., from stereo voice data to monaural voice data) so as toaccommodate sound data being transmitted via wireless link 126 tospeaker 132.

Computing device 104, as a host computing device, can be any computingdevice with a processor and memory storing executable instructions.Computing device 104 can include an application, such as a media player,that is configured to receive audio data from network 102 (e.g., musicdata) and to stream that data via wireless audio transceiver 110 tospeaker 132. Further, computing device 104 can include anotherapplication, such as a VoIP telephony application, such as Skype®, thatis configured to exchange voice data from network 102 and to stream thatdata via wireless audio transceiver 110 to a headset, such as logicalcommunication device 130. Computing device 104 can include any hardwareor processor-based platform and any operating system, such as WindowsXP®, Windows 7®, MAC OS®, etc., or any open source operating system, andthe like. Computing device 104 can include device drivers and/or data,such as audio function (“AF”) data 105, that is configured to operatewith the multiple logical audio functions or audio devices of wirelessaudio transceiver 110. During enumeration, computing device 104 can useaudio function data 105 to identify and implement multiple dataarrangements of USB descriptors.

In some embodiments, wireless audio transceiver 110 can be representedby logical entities, whereby the functions of wireless audio transceiver110 and its components can be modeled as objects or descriptors. In someembodiments, wireless audio transceiver 110 can include hardware,software, firmware, and any combination thereof. In some embodiments,communication channel controller 112 can be implemented as USBcontroller 112, which is configured to communicate with computing device104 in accordance with communication protocols, such as USB protocols. AUSB controller 112 can include circuitry to exchange USB signals (e.g.,D+, D− signals) over a USB communication channel 106, circuitry toreceive microphone data, including an analog-to-digital (“A/D”)converter circuit, and circuitry to transmit sound data, including adigital-to-analog (“D/A”) converter circuit. In some embodiments, alogical interface, such as an audio streaming interface (“ASI1”), can beassociated with the A/D converter and a buffer, as an endpoint, to storemicrophone data, whereas, another logical interface, such as anotheraudio streaming interface (“ASI2”), can be associated with the D/Aconverter and another buffer, as another endpoint, to store speakerdata. According to various embodiments, there can be two or more datarepresentations of the data paths as different audio functions. As such,other logical interfaces can be implemented in association with thecommunication channel over which USB signals (e.g., D+, D− signals) aretransmitted. Therefore, a first audio control interface (“ACI1”) and asecond audio control interface (“ACT2”) can be associated with, forexample, a set of USB D+ and D− signals, for example.

In some embodiments, wireless controller 114 can be implemented as aBluetooth® controller 114, which is configured to communicate withlogical communication device 130 and speaker 132 in accordance withwireless communication protocols, such as Bluetooth protocols. Bluetoothcontroller 114 can include radio frequency (“RF”) circuitry to generateand receive radio signals, circuitry to store, access and/or implementBluetooth protocols, protocol stacks, and baseband communications, aswell as digital signal processing (“DSP”) circuitry, A/D and D/Aconverter circuitry, and the like. In a specific embodiment, Bluetoothcontroller 114 includes a radio configured to transmit audio data atvarious data rates. In one example, Bluetooth controller 114 cantransmit data at 16 kHz and at 8 kHz. According to some embodiments,Bluetooth controller 114 can include transceiver 119. In operation,Bluetooth controller 114 can transmit voice data over wireless link 124with 16-bits at 8 kHz in telephony mode, when speaker data istransmitted to speaker 132. Bluetooth controller 114 can transmit sounddata over wireless link 126 with 16-bits at 16 kHz, 32 kHz, 44.1 kHz, or48 kHz in non-telephony mode, when voice data is absent.

In some instances, “higher quality” sound data refers to sound datatransmitted with 16-bits at 16 kHz (or equivalent), whereas “lowerquality” sound data refers to sound data transmitted with 16-bits at 8kHz (or equivalent). In various embodiments, “higher quality” sound datarefers to data having a higher sample rate than “lower quality” sounddata. Thus, a first data rate can be at 8 kHz, whereas a second datarate can be at 16 kHz in accordance with at least one embodiment. Theterm “data path” can describe a communications medium or channel overwhich data is transported anywhere from network 102 to logicalcommunication device 130 or speaker 132, and can describe any of theportions thereof (e.g., the data path in wireless audio transceiver170).

FIGS. 2A and 2B depict examples of various implementations of wirelessaudio transceivers, according to various embodiments. FIG. 2A is adiagram 200 of a wireless audio transceiver 110 implemented as a dongle207, according to some embodiments. As shown, diagram 200 includes alaptop as host computing device 202 having a USB port 204. Dongle 207includes a USB connector 206 and a housing 208. Also shown is a headset210 that includes a speaker at portion 212 and a microphone at portion214. Headset 210 includes a Bluetooth receiver module (“BTRX”) 211 and aBluetooth transmitter module (“BTTX”) 213 to transmit microphone data.Speaker 220 includes a Bluetooth receiver module (“BTRX”) 221. Dongle207 is configured to transmit voice data via wireless link 215 toheadset 210 and to transmit sound data via wireless link 222 to speaker220. Dongle 207 is configured to receive voice data via wireless link217 from headset 210. FIG. 2B is a diagram 250 of a wireless audiotransceiver 110 formed within a mobile computing-communication device252, according to some embodiments. As shown, diagram 250 includesmobile host computing device 252 including a wireless audio transceiver110. Also shown is a headset 210 that includes a speaker at portion 212and a microphone at portion 214. Headset 210 includes a Bluetoothreceiver module (“BTRX”) 211 and a Bluetooth transmitter module (“BTTX”)213 to transmit microphone data. Speaker 220 includes a Bluetoothreceiver module (“BTRX”) 221. Wireless audio transceiver 110 of FIG. 2Bis configured to transmit voice data via wireless link 265 to headset210 and to transmit sound data via wireless link 272 to speaker 220.Wireless audio transceiver 110 of FIG. 2B is also configured to receivevoice data via wireless link 267 from headset 210.

FIG. 3A illustrates an example of a topology of audio functions,according to an embodiment. In diagram 300, a USB audio gateway 301 isshown to include of multiple logical entities, such as audio function(“1”) 303 and as audio function (“2”) 323. In particular, a first datapath is modeled to include audio function 303, which is configured toreceive USB data 305 from a USB port (e.g., from the host computer) andto transmit speaker data 315. A second data path is modeled to includeaudio function 323, which is configured to receive microphone data 335and to transmit that data via a USB port as USB data 325 (e.g., to thehost computer).

As a logical entity, audio function 303 includes a first audio controlinterface (“ACI[1]”) 318 having an input terminal (“IT 1”) 311, afunction unit 316, which is optional, and an output terminal (“OT 1”)313. Audio function 303 also includes an audio stream interface (“ASI”)308 with an endpoint (“1”) 306 as a first interface (“I/F #1”) of USBaudio gateway 301. Audio stream interface 308 can be configured tostream audio data isochronously to a speaker (not shown). Audio function303 is a data arrangement representing an independent part of a USBaudio gateway 301 relating to the functionality of speaker data.Endpoint 306 is a buffer for receiving speaker data from the hostcomputer when audio function 303 is active. Input terminal 311 can becoupled to USB endpoint 306 to receive the speaker data. Output terminal313 can be coupled to a D/A converter (not shown). Function unit 316 canbe any function or addressable logical object that can be used to accessthe transport of speaker data. As such, a signal detector (not shown)can access the second data path via function unit 316 to determine thepresence or absent of speaker data. Or, in some embodiments, the signaldetector can monitor the state of endpoint 306 as a buffer. When active,the signal detector can infer that speaker data is present on the seconddata path, otherwise the signal detector can infer that speaker data isabsent when the buffer is inactive.

Similarly, audio function 323 is a logical entity that includes a secondaudio control interface (“ACI[2]”) 338 having an input terminal (“IT 1”)331, a function unit 336, which is optional, and an output terminal (“OT1”) 333. Audio function 323 also includes an audio stream interface(“ASI”) 328 with an endpoint (“1”) 326 as a second interface (“I/F #2”)of USB audio gateway 301. Audio stream interface 328 can be configuredto stream audio data isochronously from a microphone (not shown). Audiofunction 323 is a data arrangement representing yet another independentpart of a USB audio gateway 301 relating to the functionality ofmicrophone data. Endpoint 326 is a buffer for receiving microphone datafrom a remote communication device (e.g., a remote logical communicationdevice) when audio function 323 is active. Input terminal 331 can becoupled to an A/D converter (not shown) to receive microphone data.Output terminal 333 can be coupled to USB endpoint 326 to transmit themicrophone data as USB data 325. Function unit 336 can be any functionor other addressable logical object that can be used to access (e.g.,manipulate) the transport of microphone data. As such, a signal detector(not shown) can access the first data path via function unit 336 todetermine the presence or absent of microphone data. Or, in someembodiments, the signal detector can monitor the state of endpoint 326as a buffer. When active, the signal detector can infer that microphonedata is present on the first data path, otherwise the signal detectorcan infer that microphone data is absent when the buffer is inactive.

During enumeration, enumeration data 319 is transmitted to the hostcomputing device. Enumeration data 319 describes the logical entities,which include first audio control interface 318, input terminal 311,function unit 316, output terminal 313, audio stream interface 308, andendpoint 306. These elements are associated with a first audio interfacecollection (“AIC”), which is not shown. Further, enumeration data 319also describes the following logical entities: second audio controlinterface 338, input terminal 331, function unit 336, output terminal333, audio stream interface 328, and endpoint 326. These elements areassociated with a second audio interface collection (“AIC”), which isnot shown. Therefore, the host computer logically can view USB audiogateway 310 (e.g., in a single housing) as multiple audio devices. Notethat control endpoints are not shown for purposes of clarity, but can beimplemented.

FIG. 3B illustrates an example of a descriptor hierarchy of a USB audiogateway, according to some embodiments. In diagram 340, the USB audiogateway is shown to include multiple data arrangements, including afirst data arrangement as audio function (“1”) hierarchy 349 a and asecond data arrangement as audio function (“2”) hierarchy 349 b.Class-specific descriptors are omitted for purposes of clarity. A hostcomputer uses audio function hierarchy 349 a and audio functionhierarchy 349 b during enumeration. Device descriptor 341 a is a datastructure including data regarding USB audio gateway, including whetherthe device descriptor 341 a represents an audio function and itsinterfaces. Configuration descriptor 342 a is a data structure includingdata regarding the number of interfaces and other characteristics. Notethat device descriptor 341 b and configuration descriptor 342 b canprovide similar information, but for another data path or audiofunction. Note further that while audio function hierarchy 349 a andaudio function hierarchy 349 b are illustrated as having separate devicedescriptors 341 a and 341 b and separate configuration descriptors 342 aand 342 b, audio function hierarchy 349 a and audio function hierarchy349 b can share a common device descriptor and a common configurationdescriptor (not shown), according to some embodiments, so long as a hostcomputing device can detect the presence of multiple logical audiodevices.

Audio function hierarchy 349 a further includes a logical representationof an audio function (or portion thereof) as a data path to carryspeaker data. Audio function hierarchy 349 a includes an audio controlinterface (“ACI”) descriptor 343 a describing the number and types ofterminals and function units, if any. Next, audio function hierarchy 349a includes an audio streaming interface (“ASI”) descriptor 344 adescribing an audio stream using, for example, an isochronous endpointto transfer audio data. Further, one or more alternate audio interfacedescriptors that can be used to determine alternate settings. Forexample a zero bandwidth alternate setting can be used and a non-zerobandwidth alternate setting can be used. As such, the alternate settingof an audio streaming interface remains at a zero bandwidth settingunless audio data is detected on the corresponding endpoint. Further,audio function hierarchy 349 a includes an endpoint descriptor 345 a toassign an isochronous endpoint to communicate speaker data along a firstdata path. Note that audio function hierarchy 349 b similarly caninclude an audio control interface (“ACI”) descriptor 343 b, an audiostreaming interface (“ASI”) descriptor 344 b (with alternativesettings), and an endpoint descriptor 345 b having similarfunctionalities as described above, but for purposes of facilitatingaudio streaming via a second data path for microphone data.

FIG. 3C illustrates an example of a host computer and a USB audiogateway during enumeration, according to some embodiments. Diagram 350depicts a host computing device 351 including a component stack 352coupled via a communication channel 358 to a USB audio gateway 360 toeffect enumeration. Component stack 352 includes an application layer353, an operating system (“O/S”) layer 354, a device driver 355 and ahost controller 356 (e.g., a USB host controller), whereas USB audiogateway 360 includes two logical representations of audio devices, suchas audio function (“1”) 362 and audio function (“2”) 364, and aBluetooth controller 366. During enumeration, host controller 356interrogates USB audio gateway 360 to obtain enumeration data 359 andits descriptors indicating two data and control paths for two audiodevices. Therefore, endpoints and buffers of audio function 362 andaudio function 364 are isolated from each other (e.g., logically and/orphysically isolated).

FIG. 4 illustrates an example of a signal detector operating in relationto logical representations of audio functions, according to someembodiments. Diagram 400 depicts an audio function 403 including anaudio streaming interface 408 configured to receive speaker data as USBout data 405 and to transport speaker data 415 to a Bluetooth controller416 for transmission at one or more data rates to a remote Bluetoothreceiver (not shown). Further, diagram 400 depicts an audio function 423including an audio streaming interface 428 configured to receivemicrophone data 435 into endpoint 426 for transport to the host computeras USB in data 425. Signal detector 420 is coupled between audiofunction 423 and either audio function 403 or Bluetooth controller 416,or both. In operation, signal detector 430 is configured to monitor thestatus or activity of data in a buffer associated with endpoint 426. Ifthe buffer is inactive, signal detector 420 infers that no microphonedata 435 is streaming via the second data path (e.g., the USB audiogateway is in a non-telephony mode). In this case, signal detector 420transmits an indication signal or otherwise causes a software switch 418to gate or transition speaker data onto a wireless link that is at asecond data rate to consume the bandwidth of the Bluetooth link. But ifsignal detector 420 detects activity or data with respect to the buffer,then it infers that microphone data 435 is streaming via the second datapath (e.g., the USB audio gateway is in a telephony mode). In this case,signal detector 420 transmits an indication signal or otherwise causes asoftware switch 418 to gate or transition speaker data onto a wirelesslink that is at a first data rate (e.g., less than the second data rate)to consume less than the entire bandwidth of the Bluetooth link so thatboth speaker and voice data can be transmitted out from Bluetoothcontroller.

FIG. 5 illustrates an example of a flow for implementing multiplelogical representations of audio functions to modify the data rate ofwireless transmissions, according to some embodiments. FIG. 5 depicts aflow 500 in which enumeration occurs at 502. During enumeration, a USBaudio gateway transmits to a host computing device identifiers or datarepresentations of multiple audio functions associated with the USBaudio gateway. The host computing device, and its device drivers,interacts with the USB audio gateway as if the USB audio gateway weremultiple audio devices. At 504, the USB audio gateway determines whethermicrophone (“mic”) data is detected. If no microphone data is detected,then flow 500 continues to 506 at which a second data rate isestablished (if not already established) to transmit audio data, such assound or speaker data, to a remote media device (e.g., a remote logicalmedia device). At 510, the USB audio gateway and logical media devicenegotiate a wireless connection at the second data rate and exchangeinformation. Once a link is established at the second data rate, the USBaudio gateway at 514 selects a Bluetooth profile, such as Advanced AudioDistribution Profile (“A2DP”), via Asynchronous Connectionless Links(i.e., ACL channels) implemented in Bluetooth and in accordance withBluetooth profiles and protocols. Examples of such profiles andprotocols are set forth in standards controlled by the Bluetooth SpecialInterest Group (“SIG”). The USB audio gateway then transmits speakerdata at 518 at a second data rate over the Bluetooth link.

Should the USB audio gateway determine at 504 that microphone (“mic”)data is detected, then flow 500 continues to 508 at which a first datarate is established (if not already established) to transmit audio data,such as voice data, to a remote logical communication device, such as aheadset. At 512, the USB audio gateway and logical media devicenegotiate a wireless connection at the first data rate and exchangeinformation. Once a link is established at the first data rate, the USBaudio gateway at 516 selects a Bluetooth profile, such as a Hands FreeProfile (“HFP”), via Synchronous Connection-Oriented (“SCO”) linkimplemented in Bluetooth and in accordance with Bluetooth profiles andprotocols. The USB audio gateway then transmits voice data at 520 at afirst data rate over the Bluetooth link.

FIG. 6 illustrates an exemplary USB audio gateway in accordance withvarious embodiments. In some examples, USB audio gateway 600 may be usedto implement computer programs, applications, methods, processes, orother software to perform the above-described techniques. USB audiogateway 600 includes a bus 602 or other communication mechanism forcommunicating information, which interconnects subsystems and devices,such as processor 604, system memory 606 (e.g., RAM), storage device 608(e.g., ROM), a first communication interface 612 (e.g., a USBcontroller) to facilitate USB communications via a USB port oncommunication channel 620, and a second communication interface 613(e.g., a Bluetooth controller) to facilitate wireless communications onBluetooth link 621. Bluetooth controller can include logic forimplementing a multiple-mode transmitter 631.

According to some examples, USB audio gateway 600 performs specificoperations by processor 604 executing one or more sequences of one ormore instructions stored in system memory 606. Such instructions or datamay be read into system memory 606 from another computer readablemedium, such as storage device 608. In some examples, hard-wiredcircuitry may be used in place of or in combination with softwareinstructions for implementation. Instructions may be embedded insoftware or firmware. The term “computer readable medium” refers to anytangible medium that participates in providing instructions to processor604 for execution. Such a medium may take many forms, including but notlimited to, non-volatile media and volatile media. Non-volatile mediaincludes, for example, optical or magnetic disks and the like. Volatilemedia includes dynamic memory, such as system memory 606.

Common forms of computer readable media includes, for example, floppydisk, flexible disk, hard disk, magnetic tape, any other magneticmedium, CD-ROM, any other optical medium, punch cards, paper tape, anyother physical medium with patterns of holes, RAM, PROM, EPROM,FLASH-EPROM, any other memory chip or cartridge, or any other mediumfrom which a computer can read. Instructions may further be transmittedor received using a transmission medium. The term “transmission medium”may include any tangible or intangible medium that is capable ofstoring, encoding or carrying instructions for execution by the machine,and includes digital or analog communications signals or otherintangible medium to facilitate communication of such instructions.Transmission media includes coaxial cables, copper wire, and fiberoptics, including wires that comprise bus 602 for transmitting acomputer data signal.

In some examples, execution of the sequences of instructions may beperformed by a single USB audio gateway 600. According to some examples,USB audio gateways 600 can be coupled by communication link 620 (e.g.,LAN, PSTN, or wireless network) to another processor to perform thesequence of instructions in coordination with one another. USB audiogateway 600 may transmit and receive messages, data, and instructions,including program, i.e., application code, through communication links620 and 621 and communication interfaces 612 and 613. Received programcode may be executed by processor 604 as it is received, and/or storedin memory 606, or other non-volatile storage for later execution.

In the example shown, system memory 606 can include various modules thatinclude executable instructions to implement functionalities describedherein. In the example shown, system memory 606 includes a USB ProtocolControl module 630 to provide USB communications with a host computingdevice. According to some embodiments, system memory 606 can alsoinclude a Bluetooth Protocol Control module 632 to provide wirelesscommunications with remote devices. Also, memory 606 can include datarepresenting USB protocols 633 and Bluetooth protocols and profiles 634,as are described herein. Storage device 608, which can be the same ordifferent memory as memory 606, can include data structures 609, such asdescriptor data arrangements with audio function (“AF”) data 610.

In at least some examples, the structures and/or functions of any of theabove-described features can be implemented in software, hardware,firmware, circuitry, or a combination thereof. Note that the structuresand constituent elements above, as well as their functionality, may beaggregated with one or more other structures or elements. Alternatively,the elements and their functionality may be subdivided into constituentsub-elements, if any. As software, the above-described techniques may beimplemented using various types of programming or formatting languages,frameworks, syntax, applications, protocols, objects, or techniques. Ashardware and/or firmware, the above-described techniques may beimplemented using various types of programming or integrated circuitdesign languages, including hardware description languages, such as anyregister transfer language (“RTL”) configured to designfield-programmable gate arrays (“FPGAs”), application-specificintegrated circuits (“ASICs”), or any other type of integrated circuit.These can be varied and are not limited to the examples or descriptionsprovided.

Although the foregoing examples have been described in some detail forpurposes of clarity of understanding, the above-described inventivetechniques are not limited to the details provided. There are manyalternative ways of implementing the above-described inventiontechniques. The disclosed examples are illustrative and not restrictive.

1. A wireless USB audio transceiver comprising: a port configured toexchange data via a USB communication channel with a host computingdevice; a wireless transceiver configured to receive and transmitwireless signals, the wireless transceiver comprising: a multiple modetransmitter configured transmit the wireless signals at multiple datarates; a first data path associated with a first audio function, thefirst data path configured to transmit audio data transmitted from theport to the wireless transceiver; a second data path associated with asecond audio function, the second data path configured to transmit audiodata transmitted from the wireless transceiver to the port, the firstaudio function and the second audio function being independentlycontrolled via a first control interface and a second control interface,respectively; and an audio signal detector configured to determine thepresence of the audio data on at least one of the first and the seconddata paths, wherein multiple mode transmitter is configured to transmitthe audio data at one of the multiple data rates as a function of thepresence of the audio data on one or both of the first and the seconddata paths.